DB2 must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-74433	DB2X-00-000400	SV-89107r1_rule		Medium

Description
Authentication with a DoD-approved PKI certificate does not necessarily imply authorization to access the DBMS. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If the DBMS does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.

Description

Authentication with a DoD-approved PKI certificate does not necessarily imply authorization to access the DBMS. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If the DBMS does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.

STIG	Date
IBM DB2 V10.5 LUW Security Technical Implementation Guide	2017-11-16

Details

Check Text ( C-74359r1_chk )
The default name and location for the IBM LDAP security plug-in configuration file is: On UNIX: INSTHOME/sqllib/cfg/IBMLDAPSecurity.ini On Windows: %DB2PATH%\cfg\IBMLDAPSecurity.ini If the IBMLDAPSecurity.ini file does not exist, this is a finding.

Fix Text (F-81033r1_fix)
If an authority is granted to PUBLIC, revoke it using the appropriate variation of the REVOKE (database authorities) statement. If a privilege is granted to PUBLIC, revoke it using the appropriate variation of the REVOKE statement specific to the object on which the privilege is granted. For example, if the privileges are on a package, revoke it using the REVOKE (package privileges). DB2> Revoke Notes: To prevent the default assignment of authorities and privileges to PUBLIC when a database is created, one should use the restrictive option on the create database statement as demonstrated below: DB2> CREATE DATABASE RESTRICTIVE One can determine if a database was created with restrictive by looking at the value of restrict_access database configuration parameter using the following command at the command prompt: $db2 get db cfg http://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000981.html?cp=SSEPGG_10.5.0%2F2-12-7-181&lang=en

Fix Text (F-81033r1_fix)

If an authority is granted to PUBLIC, revoke it using the appropriate variation of the REVOKE (database authorities) statement.

If a privilege is granted to PUBLIC, revoke it using the appropriate variation of the REVOKE statement specific to the object on which the privilege is granted. For example, if the privileges are on a package, revoke it using the REVOKE (package privileges).
DB2> Revoke

Notes: To prevent the default assignment of authorities and privileges to PUBLIC when a database is created, one should use the restrictive option on the create database statement as demonstrated below:
DB2> CREATE DATABASE RESTRICTIVE

One can determine if a database was created with restrictive by looking at the value of restrict_access database configuration parameter using the following command at the command prompt:

$db2 get db cfg

http://www.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0000981.html?cp=SSEPGG_10.5.0%2F2-12-7-181&lang=en